
UNITED STATES PATENT AND TRADEMARK OFFICE 



Mail Stop Appeal Brief 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



Re: 



1 hereby certify that this correspondence is being deposited 
with the United States Postal Service with sufficient postage as 
first class mail in an envelope addressed to: Mail Stop Appeal 
Brief, Commissioner for Patents, P.O. Box 1450, 
Alexandria, VA 22313-1450 on 

January 9, 2006 

(Date of Deposit) 

Harold C. Moore 



Name of pers^ 



TsopjiiaiJingC 



Document or Fee 



Signature 



January 9. 2006 



Date of Signature 



Application of: 
Serial No.: 
Filed: 
For: 



Group Art Unit: 

Examiner: 

Our Docket No.: 

Siemens Docket No. 



Soemo et al. 

09/966,738 

September 28, 2001 

A Proprietary Protocol for a System 

Controller for Controlling Device 

Controllers on a Network Having an Open 

Communication Protocol 

2142 

Cheryl M. Reid 

1867-0084 

2001P18038US 



TRANSMITTAL OF BMEF ON APPEAL 

Please find for filing in connection with the above patent application the following 
documents: 



1 . Original of the Appeal Brief; 

2. Check in the amount of $500.00; and 



5 . One ( 1 ) return post card. 



Commissioner for Patents 
January 9, 2006 
Page 2 

Enclosed please find a check in the amount of $500.00 to cover the filing fee of a 
Brief on Appeal as required by 37 C.F.R. § 1.17(c). Please charge any deficiency, or 
credit any overpayment to Deposit Account No. 13-0014. 



Respectfully Submitted, 



MAGINOT, MOORE & BECK, LLP 




January 9, 2006 



Registration No. 37,892 
Chase Tower 

1 1 1 Monument Circle, Suite 3250 
Indianapolis, IN 46204-51 15 



Enclosures 



1867-0084 
2001P18038US 




IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Mail Stop Appeal Brief - Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

I hereby certify that this correspondence is being deposited 
with the United States Postal Service with sufficient postage as 
first class mail in an envelope addressed to: Mail Stop Appeal 
Brief-Patents, Commissioner for Patents, P.O. Box 1450, 
Alexandria, VA 22313-1450 on January 9. 2006 

(Date of Deposit) 

Harold C. Moore 

Name of peFsSnraiailing Document or Fee 



Re: 




Signature 
January 9, 2006 



Application of: 
Serial No.: 
Filed: 
For: 



Group Art Unit: 
Examiner: 
Our Docket No. 



Date of Signature 

Soemo et al. 
09/967,738 
September 28, 2001 

A Proprietary Protocol for a System Controller 
for Controlling Device Controllers on a Network 
Having an Open Communication Protocol 
2142 

Cheryl M. Reid 
1867-0084 



Siemens Docket No.: 2001P18038US 



BRIEF ON APPEAL 



Sir: 

This is an appeal under 37 CFR § 41.31 to the Board of Patent Appeals and 

Interferences of the United States Patent and Trademark Office from the final rejection of 

claims 1-41 of the above-identified patent application. Claims 1-13, 15-39 and 47-51 were 

rejected in the Final Office Action dated August 9, 2005. A check in the amount of 

$500.00 is enclosed herewith to cover the fee required under 37 CFR § 41 .20(b)(2). Also, 
01/1E/H006 EfiREGftYl 0000005E 099&6738 
01 FC:140E 'iOO-00 OP 

1 



1867-0084 
2001P18038US 

please provide any extension of time which may be necessary and charge any fees which 
may be due to Deposit Account No. 13-0014, but not to include any payment of issue fees. 

(1) REAL PARTY IN INTEREST 

Siemens Building Technologies, Inc. is the owner of this patent application, and 
therefore the real party in interest. 

(2) RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences in this case. 

(3) STATUS OF CLAIMS 

Claims 1-13, 15-39 and 47-53 are pending in the application. 

Claims 1-13, 15-39 and 47-51 stand rejected and form the subject matter of this 
appeal. Claims 1-13, 15-39 and 47-53 are shown in the Appendix attached to this Appeal 
Brief. 

(4) STATUS OF AMENDMENTS 

Applicants filed a Response to Office Action dated May 16, 2005 ("Response") 
responsive to an Office Action dated January 14, 2005 (First Office Action). A Final 
Office Action dated August 9, 2005 was designated by the Examiner to be responsive to the 
Response. 
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(5) SUMMARY OF THE CLAIMED SUBJECT MATTER 

Claim 1 is directed to a proprietary communication protocol for use in a system 
controller that includes an application controller and a plurality of applications for 
controlling a plurality of device controllers on a control network by using data relating to 
system points that correspond to data variables in the network. As shown in Figs. 1 and 2 
of the Application, an exemplary embodiment of the invention of claim 1 includes a system 
controller that includes an application controller in the form of NPRA 104, a plurality of 
applications in the form of applications 102, and a plurality of device controllers 1 12 and 
1 16. (See Specification at p. 5, line 28 to p.6, line 17; see also id at p.8, lines 11-16). The 
Specification discusses system points SPs, which map to system variables as SVs. 
(Specification at p.6, lines 30-33; p.7, lines 1-3; page 8, lines 3-10). 

Referring again generally to claim 1, the proprietary communication protocol 
includes a plurality of predefined messages transmitted between the application controller 
and the applications for instructing the application controller to perform a function relating 
to a select system point. In the embodiment described in the Specification, the applications 
102 send messages to the NPRA 104 requesting various operations on system points or SPs. 
(See id. at p.8, line 1 1-16; see also p. 14, lines 25-27; p. 15, lines 14-15). As claimed, the 
predefined messages include messages for reporting to the application in response to the 
instruction. (See e.g. id, at p. 18, lines 13-15 and lines 21-23). The plurality of messages 
includes a discover message transmitted by the applications to the application controller for 
inquiring whether a select system point is stored in a database of the application controller. 
(See e.g., id. at p. 12, lines 19-21). 
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The proprietary protocol includes a message identification field and a protocol 
identification field. (See, e.g., id. at Fig. 5, elements 162 and 164). 

Claim 47 is directed to a proprietary communication protocol for use in a system 
controller that includes an application controller and a plurality of applications for 
controlling a plurality of device controllers on a control network by using data relating to 
system points that correspond to data variables in the network. As shown in Figs. 1 and 2 of 
the Application, an exemplary embodiment of the invention of claim 1 includes a system 
controller that includes an application controller in the form of NPRA 104, a plurality of 
applications in the form of applications 102, and a plurality of device controllers 1 12 and 
116. (See Specification at p.5, line 28 to p.6, line 17; see also id. at p.8, lines 11-16). 

Referring again generally to claim 47, the proprietary communication protocol 
includes a plurality of predefined messages transmitted between the application controller 
and the applications for instructing the application controller to perform a function relating 
to a select system point. In the embodiment described in the Specification, the applications 
or clients 102 send messages to the NPRA 104 requesting various operations on system 
points or SPs. (See id. at p.8, line 11-16; see also p.l4, lines 25-27; p. 15, lines 14-15). As 
claimed, the predefined messages include messages for reporting to the application in 
response to the instruction. (See e.g. id. at p. 18, lines 13-15 and lines 21-23). 

The proprietary protocol includes a message identification field and a protocol 
identification field. (See, e.g., id. at Fig. 5, elements 162 and 164; p. 9, lines 15-16). The 
protocol also includes a field for indicating at least one element value of the select system 
point. (See id. at Fig. 5, element 174; p.lO, lines 38-32). The protocol further includes a 
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field for determining a format for displaying said element values. (See id. at Fig. 5, element 
176; p. 11, lines 1-6). 

(6) GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1-5, 8, 10-13, 15-16, 18-22, 25, 27-34, 36-39 and 47-51 are 
unpatentable under 35 U.S.C. § 102(e) over U.S. Patent No. 6,763,040 to Hite (hereinafter 
"Hite"). 

Whether claims 9 and 17 are unpatentable under 35 U.S.C. § 103(a) over Hite. 

Whether claims 6-7 are unpatentable under 35 U.S.C. § 103(a) over Hite in view of 
U.S. Patent Publication No. 2002/0174240 Al to Nason et al (hereinafter "Nason"). 

Whether claims 23-24, 26 and 35 are unpatentable under 35 U.S.C. § 103(a) obvious 
over Hite in view of U.S. Patent No. 6,775,692 to Albert et al. (hereinafter "Albert"). 

(7) ARGUMENT 

I. Hite Does Not Anticipate Claim 1 

In the August 9, 2005 Final Office Action, the Examiner rejected claim 1 as 
allegedly being anticipated by Hite. As will be discussed below in detail, Hite does not 
teach, show or suggest each and every element of claim 1 . As a consequence, it is 
respectfully submitted that the anticipation rejection of claim 1 should be reversed. 

A. Hite 

Hite teaches a system in which a control area network, which uses a proprietary 
protocol, may be controlled and/or monitored via the Internet using standard Web 
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interfaces. These systems are shown in Fig. 8 of Hite. Fig. 1 of Hite also shows a standard 
web browser 23, 24 that interfaces to a control area network via the Internet and a control 
network portal 12. This configuration allows for user access to control information using 
standard Internet web browsers, which use standard protocols. (Col. 4, lines 1-44). 

In contrast to the standard web protocols, the control network portal 12 uses a 
proprietary protocol to commvmicate with the control area network 34. Fig. 3 shows the 
portal 12 as including a web server 13 having standard CGI and ASP functionalities, and an 
Internet Appliance server 14 (or 320 of Fig. 3) that performs the protocol conversion to the 
proprietary protocol. (See Hite at col. 6, lines 1-8 and col. 9, lines 39-43). It is the control 
area networks, and not the Internet Web Browsers, that use the control network message 
protocol of columns 12-51. {Id at col. 9, line 51 to col. 11, line 49). 

The proprietary protocol defines a packet having a protocol field, a length of data 
field, a data field, and a checksum. The protocol field indicates the type of protocol. The 
length of data field lists the length, in bytes, of the data field. The data field contains the 
sub protocol data and the checksum determines the integrity of the packet. (Hite at 
Abstract). 

B. Hite Does Not Teach a Discover Message as Claimed 

Hite fails to teach, show or suggest "a discover message transmitted from the 
applications to the application controller for inquiring whether the select system point is 
stored in a database of the application controller", as recited in claim 1 . The Examiner has 
failed to allege a prima facie case of anticipation because the Examiner identifies no portion 
of Hite that discusses a message that inquires whether a system point is stored in an 
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application controller. 

As claimed, "system points" are elements that correspond to data variables in the 
network. Nonlimiting examples of system points provided in the specification include a 
room temperature, a room temperature set point, or the like. (Specification at p.8). 

1. The Examiner's Rejection 

In the rejection of claim 1 , the Examiner asserted that the claimed discover message 
was taught in two places of Hite. In particular, the Examiner alleged that Hite disclosed: 

plurality of messages include a discover message transmitted from the applications to the 
application controller for inquiring whether the select system point is stored in a database of 
the application controller (Col 3, lines 55-58, Col 9, lines 25-41). 

(Final Office Action at p.3). 

Applicants submit that the above-cited portions of Hite do not teach or suggest a 
discover message that inquires as to whether an element corresponding to a data variable, 
i.e. a system point, is stored in any database, much less the database of the application 
controller. The portions of Hite cited by the Examiner as teaching the claimed discover 
message are set forth below: 

. , . Content providers 25 and 26 are typically web servers that generate and provide static 
and/or dynamic information and content in the form of web pages. Content provider 
applications executing on the web server are able to mine data stored in databases (not 
shown). The web pages . . . 

(Hite at col. 3, lines 55-58) 

Databases 3 14 are operable to store information that can be used by web servers 3 12 to 
provide content that may be required by a control area network device 326. This can 
include information such as CD lists, television listings, sports data, stock information or 
any other type of information that may be used by control access network device 326. 

(Hite at col. 9, lines 25-31). 

The above quoted portions of Hite do not teach a discover message in which an 

application inquires as to whether a particular point is stored in the database of an 
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application controller. In fact, the above quoted portions of Hite do not teach any message 
that inquires as to whether a particular point is stored in any database. Instead, these 
portions of Hite merely teach that database information may be formulated into a web page 
and then provided to another application. There is no indication that the application 
requesting the information generates an inquiry regarding whether or not a specified system 
point is stored. 

Thus, the Examiner has failed to set forth a prima facie case of anticipation. The 
Examiner has incorrectly contended that formulating web pages using system data, as 
disclosed in Hite, constitutes a teaching of "a discover message transmitted from the 
applications to the appUcation controller for inquiring whether the select system point is 
stored in a database of the application controller", as claimed. Formulating web pages does 
not require a "discover" message either inherently or expressly. 

For at least this reason, the rejection of claim 1 as anticipated by Hite should be 
reversed. 

II. Claims 2-5. 8. 10-13. 15-16. 18-22. 25. 27-34 and 36-39 

Claims 2-5, 8, 10-13, 15-16, 18-22, 25, 27-34 and 36-39 also stand rejected as 
allegedly being unpatentable over Hite. Claims 2-5, 8, 10-13, 15-16, 18-22, 25, 27-34 and 
36-39 all depend from and incorporate all of the limitations of claim 1. Accordingly, for at 
least the same reasons as those set forth above in connection with claim 1 , it is respectfully 
submitted that the anticipation rejections of claims 2-5, 8, 10-13, 15-16, 18-22, 25, 27-34 
and 36-39 should be reversed. 
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A. The Rejection of Claims 3-5 Should be Reversed for Additional Reasons. 

The rejection of claim 3 should be reversed for additional reasons. Claim 3 includes 
a limitation directed to the protocol including a "system point identification field" for 
identifying the select system point. As discussed above, a system point is an element that 
corresponds to a network variable. A variable, as is known in the art, is something that 
changes. 

In the rejection of claim 3, the Examiner cites col. 4, lines 10-20 of Hite as teaching 
a system point identification field. (Final Office Action at p.4, cited the First Office Action 
at p.3). Column 4, lines 10-20 of Hite teach the use of an URL request for a web page. A 
URL request does not identify a system point. A URL merely constitutes an address of a 
database, not an identification of network variable. 

Moreover, a URL request is not part of a "proprietary protocol". URL requests 
constitute a part of the standard, open source World Wide Web command, as clearly taught 
by Hite at col. 4, lines 1-38. Thus, the URL request of Hite cannot constitute a system point 
identification field of a proprietary communication protocol. While Hite appears to teach 
a proprietary protocol at cols. 12-51, that proprietary protocol does not include a URL 
request generated by an application and sent to a web server, as taught by Hite at col. 4, 
lines 1-38. 

It is therefore respectfully submitted that the Examiner has failed to make out a 
prima facie case of anticipation. Accordingly, for reasons independent of those discussed 
above in connection with claim 1, it is respectfully submitted that the anticipation rejection 
of claim 3 should be reversed. 

Claims 4 and 5 depend from claim 3. Accordingly, the rejections of claim 4 and 5 
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over Hite should be reversed for at least all the reasons set forth above in connection with 
claim 3. 

B. The Rejection of Claim 1 1 Should be Reversed for Additional Reasons. 
The rejection of claim 1 1 should be reversed for additional reasons. Claim 1 1 

includes a limitation directed to the protocol including a "field for determining a format for 
displaying the element values [of a select system point]". 

In the rejection of claim 1 1, the Examiner cites col. 15 of Hite as teaching message 
field determining a format for displaying element values of a system point. (Final Office 
Action at p.4, cited the First Office Action at p. 5). The word "display", however, is not 
mentioned or implied in column 15 of Hite. Instead, column 15 of Hite lists several 
messages that define "data formats" for messages. Hite does not disclose that such data 
formats are in any way related to display. 

It is therefore respectfully submitted that the Examiner has failed to make out a 
prima facie case of anticipation of claim 1 1 . Accordingly, for reasons independent of those 
discussed above in connection with claim 1, it is respectfixlly submitted that the anticipation 
rejection of claim 1 1 should be reversed. 

C. The Rejection of Claim 29 Should be Reversed for Additional Reasons. 
The rejection of claim 29 should be reversed for additional reasons. Claim 29 

includes a limitation directed to the protocol including a "message transmitted ... for 
canceling a previously transmitted message". 

In the rejection of claim 29, the Examiner cites coL 43, lines 34-45 of Hite. (Final 
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Office Action at p.4, cited the First Office Action at p.8). This portion of Hite discusses 
commands that add and delete IP addresses from an IP address list. In other words, a 
command "Add IP Address" may be used to add an IP address to a list of IP addresses, and 
a command "Delete IP Address" may be used to remove an IP address. A message that 
causes a piece of data to be deleted from a database list, such as an IP address list, does not 
constitute a "message . . . canceling a previously transmitted message". Deleting a piece of 
data does not relate to or identify any particular prior message. 

Without more, it would appear that the Delete IP Address message does not 
intercept, cancel, or even refer to a prior message of any type. (See Hite at col. 43, lines 42- 
44). 

It is therefore respectfully submitted that the Examiner has failed to make out a 
prima facie case of anticipation. Accordingly, for reasons independent of those discussed 
above in connection with claim 1, it is respectfully submitted that the anticipation rejection 
of claim 29 should be reversed. 

III. Claims 6 and 7 

Claims 6 and 7 stand rejected as allegedly being unpatentable over Hite in view of 
Nason. Claims 6 and 7 depend from and incorporate all of the limitations of claim 1 . The 
modification of Hite proposed by the Examiner in connection with the rejection of claims 6 
and 7 does not overcome the deficiencies of Hite with respect to claim 1 . Accordingly, for 
at least the same reasons as those set forth above in connection with claim 1 , it is 
respectfully submitted that the anticipation rejections of claims 6 and 7 should be reversed. 
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A. The Rejection of Claims 6 and 7 Should be Reversed for Other Reasons 
The rejection of claims 6 and 7 should be reversed for additional reasons. Claim 6 
(from which claim 7 depends) includes a limitation directed to the protocol including a 
"priority field for determining whether data relating to the select system point can be 
written to". In other words, the priority field determines whether a data value may be 
written to. 

In the rejection of claim 6, the Examiner admits that Hite fails to teach a priority 
field. (Final Office Action at p.4 citing First Office Action at p. 13). To overcome this 
admitted deficiency, the Examiner alleges that Nason teaches a priority field, and cites 
Nason paragraph [0099] as providing that teaching. Paragraph [0099] of Nason is set forth 
below: 

22 sysToken: 4 bytes, unsigned long integer, System defined "token" that must be passed 
back with the corresponding Close Transmit Stream Request. sysStrmID: 4 bytes, unsigned 
long integer, System provided stream ID. This field denotes the B channel the connection 
should assume. strmCodec 4 bytes, unsigned long integer (bitmap), System selected 
CODEC to use, Multiple CODECs may be logically Ored into this field, 
strm Frames izelnMS 4 bytes, unsigned long integer. Preferred CODEC frame size for the 
TX stream (in milliseconds) destStrmlpAddress: structure ip_addr 4 bytes, unsigned long 
integer, The IP address of the device to transmit to. ipjort 2 bytes, unsigned short integer, 
port number used by the device that will be transmitting to the phone. Note that due to long 
word alignment, there may be two bytes of filler following this field. qosLevel 4 bytes, 
unsigned long integer, QoS level requested. If O.times.flffffff, then no 802. IQ tag, else if 0-7, 
assume 802. IQ tag and set priority field to the qosLevel noSilence 4 bytes, unsigned long 
integer noSilence = 0: disable silence suppression on the Tx stream noSilence = 1 : enable 
silence suppression on the Tx stream 

As best understood, it appears that Nason teaches the use of priority levels for determining 
the order in which packets are to be processed. To this end, it is noted that Nason relates to 
"Internet Protocol (IP) telephony, and more particularly to a method of controlling IP 
telephones within a LAN-implemented or Ethernet PBX using a specialized messaging 
protocol". (Nason at paragraph [0001]). The requirement of prioritizing packets to 
preserve sound quality in IP telephony is knovm in the art. 
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However, prioritization in this manner is not claimed. Instead, claim 6 is directed to 
a "priority field for determinining whether data relating to the select system point can be 
written to'\ as claimed. The claimed priority field does not relate to packet "throughput", 
as does the priority value of Nason. Nason does not teach or suggest priority used for the 
purpose of determining whether a data value may be written to. 

Accordingly, even if Hite were modified with Nason as proposed, the resulting 
combination would fail to arrive at a protocol having a "priority field for determining 
whether data relating to the select system point can be written to", as claimed in claims 6 
and 7. 

It is therefore respectfully submitted that the Examiner has failed to make out a 
prima facie case of obviousness. Accordingly, for reasons independent of those discussed 
above in connection with claim 1, it is respectfully submitted that the obviousness rejection 
of claims 6 and 7 should be reversed. 

IV. Claims 23,24. 26 and 35 

Claims 23, 24, 26 and 35 all stand rejected as allegedly being unpatentable over Hite 
in view of Albert. Claims 23, 24, 26 and 35 depend from and incorporate all of the 
limitations of claim 1. The modification of Hite proposed by the Examiner in connection 
with the rejection of claims 23, 24, 26 and 35 does not overcome the deficiencies of Hite 
with respect to claim 1 . Accordingly, for at least the same reasons as those set forth above 
in connection with claim 1, it is respectfully submitted that the anticipation rejections of 
claims 23, 24, 26 and 35 should be reversed. 
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V. Claims 9 and 17 

Claims 9 and 17 stand rejected as allegedly being unpatentably obvious over Hite. 
Claims 9 and 17 depend from and incorporate all of the limitations of claim 1. The 
modification of Hite proposed by the Examiner in connection with the rejection of claims 9 
and 17 does not overcome the deficiencies of Hite with respect to claim 1. Accordingly, for 
at least the same reasons as those set forth above in connection with claim 1, it is 
respectfully submitted that the anticipation rejections of claims 9 and 17 should be reversed. 

VL Hite Does Not Anticipate Claim 47 

In the August 9, 2005 Final Office Action, the Examiner rejected claim 47 as 
allegedly being anticipated by Hite. As will be discussed below in detail, Hite does not 
teach, show or suggest each and every element of claim 47. As a consequence, it is 
respectfully submitted that the anticipation rejection of claim 47 should be reversed. 

B. Hite Does Not Teach a Field Determining a Display Format as Claimed 

Hite fails to teach, show or suggest a "proprietary communication protocol 
comprising ... a field for determining a format for displaying . . . element values", as 
recited in claim 47. The Examiner has failed to allege a prima facie case of anticipation 
because the Examiner identifies no portion of Hite that discusses a message of a proprietary 
communication protocol that has a field relating to display formats for data. 
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1. The Examiner's Rejection 

In the rejection of claim 47, the Examiner asserted that the claimed display format 
field was taught in two places of Hite. In particular, the Examiner alleged that Hite 
disclosed: 

a field for determining a format for displaying said element values (Col 4, lines 24-27, Col 
22, lines 13-23). 

(Final Office Action at p.4). 

Applicants submit that the above-cited portions of Hite do not teach or suggest a 
proprietary communication protocol having a field for determining a display format. The 
portions of Hite cited by the Examiner as teaching the claimed display format field: 

. . . The web server receives the request and sends a web page filed to the web browse, 
which decodes the file to display information specified format on the screen. Web pages 
with dynamic content provided by gateway interfaces such as CGI and ISAPI are executable 
applications. . . (Hite at col. 4, lines 24-27) 

The String message is generated by the master to communicate a String. The format of a 
String is similar to a "C Language" string, however, the semantics are different. A String in 
a control system context is used to generate a "control" message. The "control" message 
could cause a laser disc player to begin playing a disc, display a message to the user of the 
system, or any number of other uses. The string will be converted, as necessary, to any 
format that the device supports as determined by the StringSize message. (Hite at col. 22, 
lines 13-23). 

The above quoted portions of Hite do not teach a display format field in a message 
in a proprietary corrmiunication protocol. In particular, the first paragraph describes 
displaying information from a web page, which uses standard, open protocol files. As 
discussed further above, Hite discloses a system that includes both an open protocol web 
browser and a proprietary protocol control area network. The first paragraph cited by the 
Examiner relates to the open protocol web browser and web pages. The formatting of web 
pages in Hite does not involve using messages of the proprietary protocol that define the 
display format. Instead, Hite appears to use predefined formats and/or standard open 
protocol formatting. In any event, mere display of data on a web page does not imply that a 
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proprietary protocol message must include a display format field. 

The second paragraph cited by the Examiner describes a String command of Hite. 
Hite teaches that the "String" of the String command has a formatted length. However, 
Hite does not teach that the String command may be displayed, formatted or otherwise. 
Hite only teaches that the String command may be used to cause a message to be displayed. 
Hite does not suggest that the displayed message is the String command itself. 

Thus, the Examiner has failed to set forth a prima facie case of anticipation. For at 
least this reason, the rejection of claim 47 as anticipated by Hite should be reversed. 

VI. Claims 48-51 

Claims 48-51 also stand rejected as allegedly being impatentable over Hite. Claims 
48-51 all depend from and incorporate all of the limitations of claim 47. Accordingly, for 
at least the same reasons as those set forth above in connection with claim 47, it is 
respectfully submitted that the anticipation rejections of claims 47-51 should be reversed. 

The rejection of claims 49-51 should also be reversed for the additional reasons set 
forth above in connection with claims 3-5. 

VII. Claims 52-53 

Claims 52-53 have not been rejected. They do not appear to have been examined, 
although they include limitations similar to claim 6. Claims 52-53 are allowable for the 
reasons discussed above in connection with claim 47, and furthermore for reasons similar to 
those set forth above in connection with claim 6. 
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(8) CONCLUSION 

For all of the foregoing reasons, claims 1-5, 8, 10-13, 15-16, 18-22, 25, 27-34, 36- 
39 and 47-51 are not anticipated under 35 U.S.C. § 102(e), and claims 6, 7, 9, 17, 23, 24, 26 
and 35 are not unpatentable under 35 U.S.C. § 103(a). As a consequence, the Board of 
Appeals is respectfully requested to reverse the rejection of these claims. 



RespectfeUy, submitted 




Harold C. Moore 
Attorney for Applicants 
Attorney Registration No. 37,892 
Maginot Moore & Beck 
Bank One Center Tower 
1 1 1 Monument Circle, Suite 3250 
Indianapolis, Indiana 46204-5115 
Telephone: (317)638-2922 



17 



1867-0084 
2001P18038US 



CLAIM APPENDIX 



Claim 1 . A proprietary communication protocol for use in a system controller that includes 
an application controller and a plurality of applications for controlling a plurality of device 
controllers on a control network by using data relating to system points that correspond to 
data variables in the network, said proprietary communication protocol comprising: 

a plurality of predefined messages transmitted between the application controller 
and the applications for instructing the application controller to perform a function relating 
to a select system point, and for reporting to the applications in response to said instruction, 
said plurality of messages include a discover message transmitted from the applications to 
the application controller for inquiring whether the select system point is stored in a 
database of the application controller; 

a message identification field for identifying a select message fi*om said plurality of 
messages; and, 

a protocol identification field for identifying said select message as being 
transmitted via said proprietary communication protocol. 

Claim 2. The proprietary communication protocol as defined in claim 1 wherein said 
proprietary communication protocol is embedded into a communication protocol of the 
control network. 

Claim 3. The proprietary communication protocol as defined in claim 1 further including a 
system point identification field for identifying the select system point. 

Claim 4. The proprietary communication protocol as defined in claim 3 wherein said 
system point identification field is a point unique identification (PUID) field for identifying 
the select system point by a unique identification number that is assigned to the select 
system point. 
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Claim 5. The proprietary communication protocol as defined in claim 3 wherein said 
system point identification field is a name identification field for identifying the select 
system point by a user-defined name that is assigned to the select system point. 

Claim 6. The proprietary communication protocol as defined in claim 1 further including a 
priority field for determining whether data relating to the select system point can be written 
to. 

Claim 7. The proprietary communication protocol as defined in claim 1 further including a 
priority field for determining whether data relating to select system point can be overridden. 

Claim 8. The proprietary communication protocol as defined in claim 1 further including a 
transaction identification field for uniquely identifying said select message from the 
plurality of predefined messages. 

Claim 9. The proprietary communication protocol as defined in claim 1 further including a 
field for indicating whether said select message is a last message being transmitted from the 
application controller to the applications. 

Claim 10. The proprietary communication protocol as defined in claim 1 further including a 
field for indicating at least one element value of the select system point. 

Claim 11. The proprietary communication protocol as defined in claim 10 further including 
a field for determining a format for displaying said element values. 

Claim 12. The proprietary communication protocol as defined in claim 1 further including a 
notification field for indicating at least one type of changes in the data relating to the select 
system point for which at least one of the applications desires subscription. 
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Claim 13. The proprietary communication protocol as defined in claim 12 wherein said 
changes include a change of value, a change of state and a change of quality relating to the 
select system point. 

Claim 15. The proprietary communication protocol as defined in claim 1 wherein said 
discover message refers to the select system point via a unique identification number 
associated with the system point. 

Claim 16. The proprietary communication protocol as defined in claim 1 wherein said 
discover message refers to the select system point via a user-defined name that is assigned 
to the select system point. 

Claim 17. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages include a message transmitted fi'om the application controller to the 
application in response to said discover message to report that the select system point is 
stored in said database. 

Claim 18. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages include a message transmitted from the applications to the application 
controller for subscribing for changes in the data relating to the select system point. 

Claim 19. The proprietary communication protocol as defined in claim 18 wherein said 
changes include a change of value, a change of state and a change of quality relating to the 
select system point. 

Claim 20. The proprietary communication protocol as defined in claim 18 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for unsubscribing for changes in the data relating to the select system 
point. 
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Claim 21. The proprietary communication protocol as defined in claim 18 wherein said 
plurality of messages include a message transmitted from the application controller to the 
applications reporting of said changes in the data relating to the select system point in 
response to said subscription message transmitted from the applications. 

Claim 22. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for overriding or writing new values in the data relating to the select 
system point. 

Claim 23. The proprietary communication protocol as defined in claim 22 wherein said 
overriding and writing message is accepted by the application controller if a priority of an 
application transmitting said message is greater than or equal to a priority of the data 
relating to the select system point. 

Claim 24. The proprietary communication protocol as defined in claim 23 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for releasing said priority of the data relating to the selected system 
point to allow an application having a lower priority than said priority of the data to 
override or write new value in the data relating to the select system point. 

Claim 25. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for requesting query of the data relating to at least one of the system 
points for specified information. 

Claim 26. The proprietary communication protocol as defined in claim 25 wherein said 
query message requests a report on all system points that have a write or override priority 
that is greater than or equal to a specified priority level of said query message. 
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Claim 27. The proprietary communication protocol as defined in claim 25 wherein said 
query message requests a report on all system points that conforms to a specified quality. 

Claim 28. The proprietary communication protocol as defined in claim 25 

wherein said query message requests a report on all system points that a status of at least 

one node of the control network. 

Claim 29. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages includes a message transmitted fi:'om the applications to the 
appHcation controller for canceling a previously transmitted message. 

Claim 30. The proprietary communication protocol as defined in claim 2 wherein said 
plurality of messages includes a message transmitted fi-om the applications to the 
appHcation controller for canceling a previously transmitted message. 

Claim 31. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for instructing the application controller to query all of the data 
variables in the network operatively connected to the application controller to determine if 
any of the data variables have been overridden. 

Claim 32. The proprietary communication protocol as defined in claim 1 wherein each of 
the system points are identified by a unique numeric value. 

Claim 33. The proprietary communication protocol as defined in claim 1 wherein the 
system points are identified by a user-defined name. 

Claim 34. The proprietary communication protocol as defined in claim 1 wherein each of 
the system points include at least one element value. 
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Claim 35. The proprietary communication protocol as defined in claim 1 wherein the 
system points have an assigned write priority and an override priority. 

Claim 36. The proprietary communication protocol as defined in claim 1 wherein the data 
relating to the system points are stored in a database of the application controller. 

Claim 37. The proprietary communication protocol as defined in claim 36 wherein said 
database stores user-defined data relating to the system points. 

Claim 38. The proprietary communication protocol as defined in claim 37 wherein said 
database stores a unique identification value of the corresponding data variables in the 
network. 

Claim 39. The proprietary communication protocol as defined in claim 37 wherein said 
database includes field for storing an address of the corresponding data variables in the 
network. 

Claim 47. A proprietary communication protocol for use in a system controller that includes 
an application controller and a plurality of applications for controlling a plurality of device 
controllers on a control network by using data relating to system points that correspond to 
data variables in the network, said proprietary communication protocol comprising: 

a plurality of predefined messages transmitted between the application controller 
and the applications for instructing the application controller to perform a function relating 
to a select system point, and for reporting to the applications in response to said instruction; 

a message identification field for identifying a select message from said plurality of 
messages; 

a protocol identification field for identifying said select message as being 
transmitted via said proprietary communication protocol; 

a field for indicating at least one element value of the select system point; and 
a field for determining a format for displaying said element values. 



23 



1867-0084 
2001P18038US 

Claim 48. The proprietary communication protocol as defined in claim 47 wherein said 
proprietary communication protocol is embedded into a communication protocol of the 
control network. 

Claim 49. The proprietary communication protocol as defined in claim 47 further including 
a system point identification field for identifying the select system point. 

Claim 50. The proprietary communication protocol as defined in claim 49 wherein said 
system point identification field is a point unique identification (PUID) field for identifying 
the select system point by a unique identification number that is assigned to the select 
system point. 

Claim 5 1 . The proprietary communication protocol as defined in claim 49 wherein said 
system point identification field is a name identification field for identifying the select 
system point by a user-defined name that is assigned to the select system point. 

Claim 52. The proprietary communication protocol as defined in claim 47 fiirther including 
a priority field for determining whether data relating to the select system point can be 
written to. 

Claim 53. The proprietary communication protocol as defined in claim 47 fiirther including 
a priority field for determining whether data relating to select system point can be 
overridden. 
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